1 Use of a Job Ticket as a Generic XML Database 

2 Technical Field 

3 The technical field is the integration and control of services in a networked environment. 

4 Background 

5 Services may be provided by one or more operating units in a computer-based network. 



6 Users of the network may generate specific tasks and send the tasks into the network to be 

7 assigned to one of the operating units . For example, a user at a computer terminal may generate 

8 a printing order using a printer driver installed on the terminal. The printer driver is used to control 

9 the printing request. In another example, a user at a computer terminal may generate a printing 
1 0 order and send the printing order into a computer network so that the printing order is completed 



11 by aprinting service. The printing order may be related to a company brochure. The printing order 

1 2 may contain unique requirements such as paper type, font size, layout, graphics, color, and other 

1 3 requirements. The user may specify that a specific printing service, such as Kinkos, prepare the 

14 company brochure. Alternatively, the computer network may include programs that suggest 

1 5 printing services to the user. 

16 To control the printing j ob, the user' s computer terminal may generate a j ob ticket. The 

17 j ob ticket includes the requirements, such as the requirements listed above, and an identification of 

1 8 the specific job that allows the job status to be tracked through the computer network. 

19 Use of the j ob ticket allows printing and similar services to be allocated to those resources 

20 (i.e., the operating units) that are best suited to completing the services. Unfortunately, current 

2 1 computer systems do not allow access to the wide variety of services existing in networked 



22 computer systems, such as the Internet. In addition, current systems require users to have some 

23 knowledge of the existing resources, and may require users to include applicable programming to 

24 communicate with the services. Furthermore, current systems do not allow a j ob request to be split 

25 among several processors. As a result, completion of the job request may take longer than 

26 necessary, and may not be completed in the most efficient, lowest-cost manner. 

27 Summary 

28 To overcome these and other problems related to use of a job ticket, a method and an 

29 apparatus allow a client to manage j ob attributes and processes using an electronic service center. 

30 The service center includes a job ticket service that allows access and modification of ajob ticket 
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1 by multiple users on a network. The method and apparatus use a network-accessible j ob ticket 

2 to relate to a specific job or content. The job ticket may be an object, such as an XML object, 

3 comprising routines and data. The content may be stored on the network and may be accessed 

4 by multiple job tickets. Storage and management of the job ticket are transparent to the user. The 

5 job ticket is stored in a common location in the network. The job ticket remains in the same 

6 location in the network, and users access only that portion of the j ob ticket required to complete 

7 a designated process. Security measures may be added to limit access to those users designated 

8 as being allowed to access the j ob ticket and the j ob file . The job ticket may include a service ID 

9 that relates the job ticket back to the originating j ob ticket service. In this way, a user who acquires 

1 0 all or part of the j ob ticket can refer back to the originating j ob ticket service (and the original, or 

1 1 as-modified, job ticket) to verify any changes and to ensure that the job ticket being accessed is 

12 up-to-date. The job ticket also includes a job ID to refer the job ticket to a specific job. 

1 3 The service center is coupled through a communications network to a front end service. 

14 The front end service allows a user to generate a service or job request. The communications 

1 5 network may be the Internet, or a local area network, for example. 

1 6 The service center includes a service bus, to which are coupled a j ob store, the job ticket 

1 7 service, and a work flow controller. Also coupled to the service center are one or more processors 

1 8 that may be controlled to complete processes and tasks defined in the job tickets. 

1 9 The job ticket service may generate and store the job tickets. Job content (e.g., a PDF file) 

20 is stored in the job store. With this structure, the user does not have to manage storage of the j ob 

2 1 content or to know which job store holds the job content. The job ticket service controls access 

22 to the j ob tickets, and, through the use of the j ob tickets, also controls access to j ob content in the 

23 j ob store, or elsewhere in the network. The j ob ticket service may create a reference to the j ob 

24 ticket, and may use the reference to control access to the job ticket. 

25 The use of job tickets allows clients to define databases, and to store data though the job 

26 ticket service. The databases may be used to hold contact lists, addresses, and other personal 

27 data. The databases may also be used to store any other generic data. The databases could then 

28 be used in conjunction with a variety of e-services provided by the processors. For example, an 

29 e-mail processor that provides e-mail services may be used in conjunction with a personal contact 

30 list to send e-mail messages, transfer electronic files, or to establish a chat room. The e-mail 
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1 processor may access the contact list at predefined intervals to send e-mail messages to a select 

2 group of e-mail addressees. Furthermore, because the service center provides a single portal to 

3 processors that are coupled to the communications network, the client need not have any 

4 knowledge of the database structure, or the processing requirements of the processors. 

5 In an embodiment, the j ob ticket may be used as a generic database in conjunction with 

6 an e-mail service. A client may have established a list of e-mail contacts. The contacts database 

7 may then be stored in the job store. A corresponding job ticket may be stored at the job ticket 

8 service. The job ticket includes control data needed to send and receive e-mail through the service 

9 center. In an embodiment, the generic database may be an XML or HTML database, or any other 

10 markup language database. The database may also be a structured query language (SQL) 

1 1 database. 

1 2 The use of the j ob ticket also allows for parsing, searching and updating the contacts 

1 3 database. For example, the client may desire to search the contacts database for phone numbers 

1 4 by name. This search functionality is included in the job ticket, and allows the job ticket service to 

1 5 provide the client with a list of phone numbers for all entries in the contacts database by name. 

1 6 Description of the Drawings 

1 7 The detailed description will refer to the following figures in which like numeral refer to like 

1 8 items, and in which: 

1 9 Figure 1 is a block diagram showing a prior art use of a job ticket; 

20 Figure 2 is a tree diagram showing the processes in an example j ob ticket; 

21 Figure 3 is a block diagram of a digital image work flow network; 

22 Figure 4 is a block diagram of a service center used with the network of Figure 3 ; 

23 Figures 5A-5D illustrate an exemplary job ticket; 

24 Figure 6 is a diagram of functions controlled by a j ob ticket service ; 

25 Figure 7 is a diagram showing access functions controlled by the job ticket service; 

26 Figure 8 is a block diagram illustrating additional control features of the job ticket service; 

27 Figure 9 is a flow chart illustrating one of the processes controlled by the job ticket service; 

28 and 

29 Figures 1 0- 1 6 are flow charts showing sub-processes in the overall process illustrated in 

30 Figure 9. 
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1 Detailed Description 

2 Figure 1 is a block diagram showing a prior art application of a job ticket service. Job 

3 tickets are often associated with a printing standard, the job definition format (JDF). The JDF is 

4 described in detail in JDF Specification Draft Spiral 4.0, available at www.hp opensource.com. 

5 which is hereby incorporated by reference . In Figure 1 , a user 1 generates a j ob request and sends 

6 the j ob request through aportal 4 to a processor 5 . The j ob request may include a j ob ticket data 

7 file 2 and a content file 3 . The user 1 may be a computer terminal in a networked computer system 

8 and the processor 5 may be a networked printer. The job request may involve printing a 

9 document. The document may be represented by the content 3 , which is a digital representation 

1 0 of text and images to be printed. The intended format of the printed document may be described 

1 1 in the j ob ticket file 2, which is simply a digital file that specifies how the printer is to print the 

1 2 document. For example, the j ob ticket file 2 may require that the document be printed on back-to- 

1 3 back pages. 



14 In a specific application, the functions of the j ob ticket file 2 may be carried out by a printer 

1 5 driver. The printer driver encodes control data related to printing the document, and sends the 

16 control data and the content 3 to the printer (i.e., the processor 5). The printer accesses the control 

1 7 data and the content 3 to print the document. 

1 8 While the application shown in Figure 1 works well to print a document, the application has 

19 many drawbacks. Inparticular, if multiple processors are involved in producing the document, 

20 each such processor will require access to the j ob ticket file 2. This access brings problems related 

21 to security, modification control and workflow control . For example, each processor requiring 

22 access to the job ticket file 2 may have to wait on processing until a prior processor has completed 

23 use of the job ticket file 2. Thus, the prior art application may result in unwanted delays in 

24 completing the j ob request. 

25 Prior art applications of job ticket services also suffer because the user may not know 

26 anything about the processors, including capabilities and availabilities of the processors, or even if 

27 the proces sors exist. Thus, the user may not know which portal to use to connect to a specific 

28 processor. 

29 These and other problems are solved by a method and an apparatus that controls access 

30 to ajob ticket and associated content through use of a job ticket service. The job ticket service 
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1 includes mechanisms that arbitrate access to the job ticket among multiple users of thejob ticket, 

2 limit access to the j ob ticket by incorporating security features, and ensure modifications made by 

3 one processor or user are reflected in the job ticket and the content. In effect, the apparatus 

4 includes a generic database that couples input data from clients as j ob requests with output services 

5 such as processors that perform tasks or processes to complete thejob requests. The database 

6 may have has the features of a generic XML database in that it is extensible, and in that the clients 

7 need not have any knowledge of the individual processes to be performed, or the internal 

8 programming requirements of the processors. Thus, the clients may submit j ob requests to a 

9 service center that will ensure that an appropriate processor or processors are assigned to complete 

10 the job request. Other database formats may also be used. 

1 1 Before describing the apparatus and method in detail, a review of a j ob ticket is provided. 

1 2 Figure 2 is a node-tree diagram (or simply a node tree) 1 0 that illustrates processes defined in a 

13 job ticket for printing a brochure. The brochure may be printed on a commercial press, and may 

1 4 use digital content to generate plates for printing the brochure. Within the node tree 1 0, the nodes 

1 5 specify a product, process, or group of processes. Each node may modify, consume or create 

1 6 resources. Each node may contain further nested nodes, or sub-nodes. The arrangement of nodes 

1 7 and sub-nodes may be likened to a tree, and each node and sub-node may be referred to as a 

1 8 branch. A brochure node 1 1 defines the features and parameters of the brochure. A cover node 

19 12 defines the parameters for producing the brochure cover. Inside pages node 1 3 includes the 

20 parameters to produce the inside pages. The inside pages node 1 3 is shown with several sub- 

2 1 nodes, including a sub-node 1 4 for digital plate making. The digital plate making sub-node 1 4 itself 

22 includes two additional sub-nodes, a ripping sub-node 16 and a plate making sub-node 18. 

23 Each of the nodes and sub-nodes shown in Figure 2 has associated with it input resources 

24 and at least one output resource. A resource may be described by parameters or logical entities. 

2 5 The resource may be a physical entity such as a component, a handling resource, or a consumable. 

26 A component resource may be the output of a node or sub-node, such as a printed sheets. A 

27 handling resource is used during a process, but is not consumed by the process. A consumable 

28 resource may be partly or wholly consumed by the process. Examples of consumable resources 

29 include inks, plates, and glue. Other resources may be a digital file or representation of a physical 

3 0 obj ect. For example, the ripping sub-node 1 6 may include as input resources a run list, media, RIP 
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1 parameters, and layout. The run list resource describes the pages, including the files in which the 

2 pages occur, and which pages are to be used. The media resource describes the media that will 

3 be used to make plates, and is needed to describe the dimensions of the media. The RIP 

4 parameters resource describes all device-specific parameters of the ripping process. The layout 

5 resource describes placement of source pages onto the plates, and eventually onto press sheets. 

6 As an output resource, the ripping sub-node 1 6 may provide ripped flats. Other resources include 

7 parameter resources, which define the details of processes, as well as other non-physical computer 

8 files used by a process. 

9 The node tree 1 0 shown in Figure 2 is intended to apply to printing a document. However, 

1 0 node-tree diagrams may be used to represent job tickets for other services besides printing. For 

1 1 example, a job ticket may be used for data processing, image processing, creating and mamtaining 

12 adatabase, electronic publishing, e-mail, and various e-commerce services. Moreover, the job 

13 ticket may be used to allow different e-commerce services to interact with each other. 

14 Figure 3 is a block diagram of a digital imaging work flow (DIW) network 20 that 

1 5 incorporates a service center and a j ob ticket service to control tasks submitted by clients. The 

1 6 service center may operate as a single portal through which the clients connect to one or more e- 

1 7 services including e-mail, e-commerce and online shopping, e-printing, and data services, including 

1 8 database searching and database construction, population and maintenance . Using a single portal, 

1 9 such as the service center, allows the clients to select from a wide variety of e-services, such as 

20 those noted above, without requiring the clients to have any prior knowledge of the e-services. 

2 1 The service center may include components that receive information in the form of j ob 

22 requests, and usingthe information, create ajob ticket that specifies tasks andresources. Thejob 

23 ticketmaybe stored in ajob ticket service, and notices may be posted to indicate when ajob ticket 

24 is available. Processors coupled to the service center may bid on completion of thejob ticket, and 

25 the service center may include abidding service that evaluates bids. The service center may select 

26 one or more processors to assign to the j ob ticket based on client-supplied criteria, or based on 

27 a set of standard criteria, including industry standard criteria. The service center may provide 

28 mechanisms to control access to thejob ticket, or to portions (branches) of thejob ticket. The 

29 mechanisms include branch locking, and authorization and authentication servers that use public key 

30 encryption, or similar processes. 

HP: 10005661-1 6 



1 The service center may include hardware components such as servers, computers, central 

2 processing units, communications interfaces, and memory devices to provide the processing 

3 capability and data storage required to carry out the above-described functions. 

4 The DI W network 20 includes a front end service 3 0 that allows a client 3 1 to generate 

5 and submit a service or job request. In an embodiment, the front end service 30 maybe anlnternet 

6 web browser. Alternatively, the front end service 3 0 may be a web application or a port monitor. 

7 The j ob request may contain detailed information about how the j ob is to be executed, and may 

8 be formatted according to the j ob definition format standard. Alternatively, the j ob request may 

9 include only basic information, which will be used by another component to finalize the job 

1 0 definition, or work flow. Finally, the j ob request may include the content, or j ob, that is to be 

1 1 processed. The content could be one or more digital files, text files, and other files. The front end 

1 2 service 3 0 is coupled to a communications network 3 5, which may be the Internet or a local area 

1 3 network, for example. Coupled to the communications network 3 5 is a service center 40 that links 

14 one or more processors 80; to the communications network 35. Each of the processors SO^ay 

1 5 include a cache 81 t that may be used to store information related to a job request, including 

1 6 information related to j ob tickets. In an embodiment, the service center 40 may be an Internet web 

1 7 site that includes data storage and control functions. In another embodiment, the service center 40 

18 is a node in a local area network. 

1 9 The service center 40 allows a broad spectrum of communications between entities coupled 

20 to the service center 40. In particular, the service center 40 allows different e-services to interact 

2 1 programmatically with one another using specific protocols and generic protocols (e.g., TCP/IP). 

22 This programmatic interaction allows different services and processes that are coupled to the 

23 network to exchange data and files, and to modify the data and files. The programmatic interaction 

24 may be completed by use of a remote procedure call (RPC) between entities coupled to the service 

25 center 40. Other methods for providing the programmatic interaction include CORBA, UDDI, and 

26 e-speak. 

27 Figure 4 is a diagram of the service center 40. The service center 40 includes a service bus 

28 4 1 in communication with the communications network 3 5 and the processors 80; of Figure 3 . 

29 Coupled to the service bus 41 is a job store 50, a job ticket service 60, a work flow controller 70, 

30 an optional bidding service 90, an authorization server 92 and an authentication server 94. The j ob 
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1 store 5 0 may store one or more j ob content files 51;. The j ob ticket service 60 may control one 

2 or more j ob tickets 61,. The work flow controller 70 may use one or more agents 7 1 , to contro 1 

3 processes on the service bus 41 . 

4 The job store 50, job ticket service 60 and work flow controller 70 function to accept 

5 information from the clients 3 1 , and to use the information to control the actions of the processors 

6 80 r The processors 80iperforms specific tasks or processes as determined by the service center 

7 40. 

8 The j ob store 5 0 may be a node on the service bus 4 1 , and may include programming to 

9 allow the j ob store 5 0 to carry out its functions. The j ob store 5 0 may be used to store the content 

10 51, which may be in the form of one or more large files. In the context of printing a document using 

11 a service or process coupled to the service bus 41 , the job store 50 may store the document 

1 2 content in one or more PDF files, for example. The content 5 1 may include graphics and text. The 

1 3 content 5 1 for a specific document may include several files. For example, a brochure may have 

14 a separate file for the cover and another file for the inside pages. Text for the inside pages may be 

15 in one file and images in yet another file. The content 5 1 may also include links to other resources 

16 or entities on the service bus 4 1 . The j ob store 5 0 provides for mass storage of the content 5 1 , so 

1 7 that a user (client 3 1 or processor 8 0) does not have to provide the mass storage required for the 

18 job content 5 1 . By using the mass storage capabilities of thejob store 50, the content 5 1 may be 

1 9 made to persist in the network 20 , and may be made acces sible to users at any time. That is, the 

20 job store 50 may store the content 51 for an extended time. Thejob store 50 also manages and 

21 controls the content so that the user (client 3 1 or processor 80) does not have to manage the 

22 content 5 1 . Management functions include maintaining configuration or version control of the 

23 content 51, controlling access to the content 51, and maintaining the content 51 in storage. 

24 Thejob ticket service 60 holds job tickets 61 . Thejob ticket service 60 controls access 

25 to and may manage configuration of the j ob tickets 6 1 . For example, thejob ticket service 60 may 

26 allow users (clients 3 1 , and processors 80,) to access a portion or branch of a job ticket 61 rather 

27 than passing thejob ticket 61 among multiple users. Access to the job ticket portion may be 
2 8 effectuated by use of an application programming interface, a scriptable interface, or a similar 

29 feature. As noted above, thejob ticket 61 does not include the content 51 (e.g., the graphical and 

30 text files ofa document), but thejob ticket 61 relates to content 51 (e.g., aPDF file) stored in the 
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1 job store 50. The user does not have to manage storage of the job content or to know which job 

2 store 50 holds the job content. The job ticket service 60 instead passes a reference in the job 

3 ticket 61. This allows multiple clients 31 and processors to access the content 51. 

4 Furthermore, the content 51 may relate to more than onejob ticket 61. Thejob ticket service 60, 

5 and its interrelationships with other entities coupled to the service bus 4 1 , will be described later 

6 in detail. 

7 Some job tickets 61 may be accessed by multiple processors 80, in either serial, 



8 overlapping, or simultaneous fashion. The multiple access processing could result in problems with 

9 use of the job ticket 61. Forexample,afirstprocessormayacquirethejobticket61 (oraportion 

1 0 or branch thereof), and perform a process specified in the work flow, which may modify the 

1 1 branch. Such modification may be to indicate a branch as complete, use up input resources, or 



12 create new output resources, for example. A second processor could attempt to acquire the 

1 3 branch, but might not ' 'know" that the first processor had modified the branch. Alternatively, if two 

14 processors compete for the same branch, a deadlock situation might occur. 

1 5 One solution to the above problems may be to lock thejob ticket 6 1 whenever a processor 

16 80 acquires thejob ticket 61. Unfortunately, locking thejob ticket 61 may prevent concurrent or 

17 parallel processing and may slow down completion of thejob request 32. 

1 8 Thejob ticket service 60 shown in Figure 4 overcomes these and other problems by having 

19 the capability to lock the job ticket 61 at the branch level. The branch locking may be 

20 accomplished by one of several methods. The work flow controller 70 may assign one or more 

2 1 specific processors 80, to perform the tasks identified with the branch to be locked. Where only 

22 one processor 80 is authorized access to the branch, branch locking may not be required. Where 

23 more than one processor 80 is authorized access to the same branch, thejob ticket service 60 may 

24 lock the branch when one of the authorized processors 80 actually acquire the branch. 

25 If the work flow controller 70 has not assigned processors 80, to branches (i.e., any 

26 processor 8 0 may access a branch at any time), the j ob ticket service 60 may lock the branch when 

27 a processor 80 acquires the branch. 

28 Thejob ticket service 60 may lock the branches by setting a lock/unlock flag for each 

29 branch. Processors 80, accessing thejob ticket 6 1 may then review the lock/unlock flag status to 

30 determine if the branch may be accessed. In some circumstances, thejob ticket service 60 may 
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1 allow access only to those branches that are unlocked. A processor 80 that has completed a task 

2 defined by the branch may need to have the branch unlocked in order to modify the branch. 

3 The work flow controller 70 may be used to create the job tickets 61 that are stored in the 

4 job ticket service 60. The work flow controller 70 may review the job requests 32 submittedby 

5 the clients 3 1 , and may then use a job ticket template to prepare the j ob ticket 6 1 . The work flow 

6 controller 70 may then send the job ticket 61 to the job ticket service 60 for storage and 

7 processing. 

8 The work flow controller 70 also controls completion of tasks among the processors 80j. 

9 In an embodiment, the work flow controller 70 determines which of the processors 80 have the 

1 0 necessary and available resources to begin the processes listed in a specific j ob ticket 6 1 . The 

1 1 work flow controller 70 then designates the appropriate processors 80^ to complete the tasks 

1 2 referenced by the j ob ticket 6 1 . For example, if a j ob ticket 6 1 1 requires color printing, the work 

13 flow controller 70 may determine that only processor 80 3 is a color printer with the capacity to 

1 4 begin the j ob specified in the j ob ticket 6 1 j . This embodiment in which the work flow controller 

15 70 determines which processors 80, to assign to a specific job ticket 61 may be especially 

16 appropriate when the network 35 is a local area network and all processors 80, are directly 

17 coupled to the local area network 35. 

1 8 Alternatively, the work flow controller 70 may receive bid information from Internet- 

1 9 connected processors 80, and may use the bid information to select the processors 80, to complete 

20 the job request 32. 

2 1 The work flow controller 70 may also be used to designate the various nodes, input and 

22 output resources, and other features of the node tree used to complete the job request. That is, the 

23 work flow controller 70 may be used to create a construct, or work flow, such as the node tree 

24 10 shown in Figure 2. To accomplish these tasks, the work flow controller 70 may include one or 

25 more agents 7 1 ; that write a j ob definition file, based on control data contained in the j ob request 

26 32. Alternatively, a separate management information system (not shown) may be used to create 

27 the nodes, and to control flow of tasks to the processors 80, and other entities. In yet another 

28 embodiment, the job definitions may be written by the client 3 1 that originated the job request 32. 

29 Referring again to the node tree 1 0 of Figure 2, many output resources of the individual 

30 nodes serve as input resources for other nodes. These other nodes may not be able to begin 
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1 executing until all input resources are complete and available, which means that the nodes may need 

2 to execute in a well-defined sequence. For example, a process for making plates will produce 

3 press plates as an output resource that is required by a printing process. In the hierarchical 

4 organization of the node tree 1 0, nodes that occur higher in the node tree 1 0 represent higher-level, 

5 more abstract operations, while lower order nodes represent more detailed, specific processes. 

6 Moreover, nodes near the top of the node tree 10 may represent only intent regarding the 

7 components or assemblies that comprise the product, and lower level nodes provided the detailed 

8 instructions to a processor 80 to perform a specific process. 

9 Because two node trees may not be similar, the work flow controller 70 may determine 

1 0 processes to be completed, the order in which the processes are completed, and the processors 

1 1 80, that are to complete the processes. The work flow controller 70 may use the agents 7 1 to 

1 2 determine an actual work flow, considering factors such as control abilities of the processors 80, 

1 3 that complete the processes, transport distances between processors 80„ load capabilities of the 

14 processors, andtime constrains inthejob request, for example. Theagents71 maydefinethe 

1 5 overall process using serial processing, which involves subsequent production and consumption of 

1 6 resources by the processors 80 15 overlapping processing, which involves simultaneous consumption 

1 7 and production of resources by more than one processor 80„ parallel processing, which involves 

1 8 sharing resources among processors 80, and iterative processing, which involves a back and forth 

19 processing scheme to develop resources. 

20 Returning to Figure 4, the processors 80, may be used to provide data services to the 

2 1 clients 3 1 . However, each processor 80 can have a unique interface, data format, query syntax, 

22 security protocol, and the like. For example, the processor 80j maybe configured as a web server 

23 and so responds to hypertext transfer protocol (HTTP) request packets and generates responses 

24 formatted as hypertext markup language (HTML) web pages. In contrast other processors 80, 

25 may use file transfer protocol (FTP) or other available transfer protocols, both public and private. 

26 In a particular example, each of the processors 80 1 - 80 3 implements a database web 

27 server that hosts a "website" having a predefined structure and access syntax and protocol. In 

2 8 general each website is designed to provide information about its database content response to 
29 queries (job requests) communicated through network 20. Because each processor 80! may be 

3 0 created and maintained by a separate organization, there is no uniform interface provided for 
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1 interacting with the various processors 80 t . For example, the databases may relate to customer lists 

2 in an e-commerce application, and the processor 80 1 may enable searches by last name, phone 

3 number, zip code, or other searchable fields whereas the processor 8 0 2 may enable searches only 

4 by last name. Accordingly, and in the absence of the service center 40, the j ob requests 32 must 

5 differ in content to evoke the desired response from each processor 80^ Also, the processor 80 x 

6 may require that a query be processed through a series of pages before a response is generated. 

7 In contrast, the processor 80 2 may allow direct, one-page access to submit queries and generate 

8 responses. Hence, the processor 80 t will require a series of communication packets to be received 

9 before the desired response is generated whereas the processor 80 2 is potentially accessed with 

1 0 a single communication packet that encapsulates the desired query data. 

1 1 The service center 40 serves as an interface between the client 3 1 and the various 

1 2 processors 80 i; and allows the client to submit data queries (job requests) without having any prior 

13 knowledge of the database being searched, and its associated search engines. 

14 In determining which of the processors 80; to assign to complete a particular j ob request, 

1 5 the work flow controller 70 may poll the processors 80, that are coupled to the service center 40. 

1 6 As noted above, the processors 8 0, may be coupled directly to the service bus 4 1 , or may be 

1 7 coupled indirectly through another communications bus, such as the Internet, for example. The 

18 pollingmayoccurwheneverajobticket61 is created by thejob ticket service 60. Alternatively, 

1 9 the polling and corresponding information collection may occur on a periodic basis, and the work 

20 flow controller 70 may store information related to the processors 80. 

21 As an alternative to polling, processors 80 t coupled to the service center 40 may monitor 

22 thejob ticket service 60. Thejob ticket service 60 may periodically post, in a bulletin board 

23 fashion, for example, notices for job tickets that are available for processing. The processors 80j 

24 may then submit a bid for the tasks and processes defined in the j ob ticket notice. The work flow 

25 controller 70, or the separate, optional bidding service 90, may reviewthe bids, and determine 

26 which single processor 80 or combination of processors 80; would be best suited to complete the 

27 tasks and processes defined in the job ticket notice. 

2 8 The service center 40 may include several features to provide security and to control access 
29 to thejob ticket 6 1 . As discussed above, thejob ticket service 60 may include aprovision for 

3 0 branch locking. In addition, servers may be used to authorize and authenticate a processor 80 and 
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1 maintain the authorization and authentication during completion of a job request 32. The 

2 authentication server 92 receives authentication information from a processor 80 and the 

3 authorization server 94 uses the information to check authorization functionality. The authorization 

4 or access rights of the processor 80 may be carried as a part of the job ticket 6 1 . The servers 92 

5 and 94 may be hardware devices, but need not exist in the same hardware platform, and the 

6 servers 92 and 94 need not be tightly coupled. Alternatively, the functions of the servers 92 and 

7 94 may be performed in programming stored in one of the components of the service center 40, 

8 such as the work flow controller 70, for example. Using the above-described features, the service 

9 center 40 may provide trusted authentication information about the processor 80 to the 

1 0 authorization server 94, and the authorization server 94 then performs its authority check functions. 

1 1 Thejob ticket 61 maybe signed with an industry standard public key encryption message 

1 2 digest (MD) signature, and may be protected by apublic key encryption system. Hence, any user 

1 3 that has the public key may validate the j ob ticket 6 1 without having to communicate with the 

14 authentication server 92. These features reduce communication between distributed server 

15 applications. The features also allowthe job ticket 61 to be passed from one processor 80 to 

1 6 another processor 80, maintaining security, without communicating with the service center 40. 

17 man alternative embodiment, thejob ticket61 holds authentication/access data, allowing 

1 8 controlled access within the service center 40 infrastructure. Resources may be protected by 

19 passwords and other mechanisms. Access to the job ticket 61 may be similarly protected. 

20 Furthermore, processors 80; with access authorization may have such access authorization invoked 

21 by listing the processors in the j ob ticket. The listing may be effectuated by recording a network 

22 address for the processors 80 15 for example. The network address may be incorporated in the bid 

23 information recorded in the j ob ticket 6 1 . 

24 Although the above description refers to development by the work flow controller 70, other 
2 5 components in the network 20 may be used to develop an overall work flow to complete the j ob 

26 request 32. For example, thejob ticket service 60 may be used to develop the overall work flow. 

27 As discussed above, the bidding service 90 may be used to receive bid information from 

28 processors 80 L coupled to the service center 40. The processors 80, submit bids in response to 

29 posting of j ob ticket notices at the service center 40 . In an embodiment, the j ob ticket notice is a 

30 separate object stored in the service center 40. Inanother embodiment, thejob ticket 61 itself 
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1 serves the notice function. The work flow controller 70 may post the job ticket notices after receipt 

2 of the j ob request 32. Whether the bidding service 90 or the work flow controller 70 receives the 

3 bids, the bid evaluation and selection process may be the same. 

4 The j ob ticket notice posted by the work flow controller 70 may include specific tasks or 

5 processes (branches) that must be completed to complete the j ob request 32 (see Figure 7). A 

6 simple job request 32 may have only one branch. More complex job requests 32, such as the job 

7 request illustrated in Figure 2 (i.e., print a brochure) may have many branches. Furthermore, some 

8 branches may be so interrelated that they can only be completed in a specific sequence, while other 

9 branches can be completed in a parallel or an overlapping fashion. This interrelationship may often 

10 be the result of one branch producing an output resource that is an input resource for one or more 

1 1 other branches . The j ob ticket notice may include descriptions of specific branches and their 

12 interrelationships in sufficient detail to allow the processors 80, to bid for completion of the 

1 3 branches. The j ob ticket notice may persist in the service center 40 for a specified time to allow 

1 4 the processors 80, to send bids. The time may be a set value (e.g., one hour) or may be based on 

15 a completion deadline specified in the job request 32. 

1 6 The bidding service 90 may select bids 9 1 from the processors 80, based on set criteria. 

1 7 For example, the job request 32 may specify minimum performance requirements (e.g., amaximum 

18 cost and a completion deadline) . The bidding service 90 may rej ect any bids that fail to satisfy the 

1 9 niinimum performance requirements. Where the work flow controller 70 has established multiple 

20 branches, each such branch may include minimum performance requirements. The branch-specific 

2 1 performance requirements may be established by the work flow controller 70 based on overall 

22 performance requirements for the j ob ticket 6 1 . A processor 80 that bids on a particular branch 

23 may be rejected by the bidding service 90 if the processor 80 fails to meet the minimum 

24 performance requirements. 

25 If the client 3 1 does not specify any minimum performance requirements, the bidding 

26 service 90 may apply a standard set of criteria (e.g., an industry standard). In addition, the bid 

27 must satisfy any requirements for producing output resources. In this way, bids that are made in 

28 error, or that would otherwise likely be rejected, can be screened out. For example, a bid for 

29 printing inside pages of the brochure may indicate a one year completion date. Such a bid may be 

30 rejected, even in the absence of any specified performance requirements from the client 3 1 . 
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1 In addition to submitting performance requirements, the client 3 1 may specify an evaluation 

2 algorithm for evaluating bids. For example, the client 3 1 may specify that cost is to be weighted 

3 twice as much as any other performance requirement. 

4 In the absence of a client-specified evaluation algorithm, the bidding service 90 may apply 

5 a standard evaluation algorithm in order to rank bids for each branch in the work flow. The 

6 evaluation algorithm may apply weighting criteria, or may apply a default rule. For example, bids 

7 may be ranked based on a maximum score, where points are awarded for cost estimates below 

8 a maximum and for completion times below a maximum. Once the evaluation algorithm has been 

9 applied, the bidding service 90 ranks the bids for each branch. If only one processor 80 survives 

10 the process, that processor 80 may be automatically selected and assigned to the branch. If 

1 1 multiple processors 80, survive, the bidding service 90 may provide a list of such processors 80 l 

12 to the work flow controller 70, which will then select the processors 80, to be assigned to the 

1 3 branches. Alternatively, the list may be provided to the client 3 1 , and the client 3 1 may select the 

14 processor(s) 80j to complete the tasks defined in the work flow. 

1 5 The work flow controller 70 may associate winning bids with corresponding branches, and 

1 6 may store the bid information with the job ticket 6 1 . The stored bid information may include 

1 7 identification information that allows the authorization server 94 and the authentication server 92 

18 to permit access to job ticket branches or to the entire job ticket 61 . Because the bid information 

19 is stored with the job ticket 6 1 , a processor 80 may access those branches for which the processor 

20 80 is authorized access without having to communicate directly with the j ob ticket service 6 1 . This 

2 1 feature allows the j ob ticket 60 to be passed from one processor 80 to another processor 80, 

22 which improves processing time and efficiency. 

23 In an embodiment, the work flow controller 70 accesses control data of the job ticket 6 1 



24 to determine which processor(s) 80, should be assigned to the specific task identified in the j ob 

25 ticket. The work flow controller 70 may also identify which of the processors 8 0j would be able 

26 to meet the criteria specified in the control data, and may provide a list of such processors 8 0, to 

27 the client through the front end service 30. Theclient31 maythen select a processor(s) 80,from 

28 the list. 

29 The job ticket service may, in an alternative embodiment, be implemented in whole or in 
3 0 part by storing program instructions on a computer-readable medium, such as a CD-ROM, for 
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1 example. A computer processor may then implement method steps to provide the job ticket 

2 service by reading and executing the program instructions. 

3 Figure 5A illustrates an exemplaryjob ticket 61. Thejob ticket 61 may include two parts. 

4 A first part includes a framework 62 and an optional client extension 64. The framework 62 

5 includes information, files and programming necessary to control tasks defined in the j ob ticket 6 1 . 

6 The client extension 64 may include information related to a specific client (machine) and to a user 

7 of the machine. A second part includes a security module 67 that protects the j ob ticket 6 1 from 

8 unauthorized access. 

9 The framework 62 may include ajob identification (ID) 63, a service ID 65, atask section 

10 68, and control data 69. Thejob ID 63 includes areference to a specific job, or content 51 that 

11 is stored in thejob store 50. Thejob ID63 also includes a reference to a particularjob store 50 

1 2 that is used to store the content 5 1 . An entity that acquires a reference to the j ob ticket 6 1 can use 

13 the j ob ID 63 to access the corresponding content 5 1 . Thus, the network 20 shown in Figure 3 

14 may include multiple job stores 50, and thejob ID63 may be used to correlate thejob ticket 61 

15 to a specific job store 50. The service ID 65 identifies a specific job ticket service 60 that stores 

16 the j ob ticket 61. For example, the network 20 may include multiple j ob ticket services 60 (not 

1 7 shown in Figure 3). The service ID 65 is used to correlate thejob ticket 6 1 to the appropriate j ob 

18 ticket service 60. 

1 9 The tasks section 6 8 (Figure 5B) may include branch definitions, and other information 

20 needed to control completion of the branches. The tasks section 68 may be structural so that each 

2 1 branch or node in a node tree is represented by one or more branches 66; in the tasks section 68 . 

22 In this embodiment, each node in the node tree (e.g., the mode tree 1 0 of Figure 2) can have 

23 associated with the node, the description 95, resources 96, lock/unlock flag 97, and security 

24 features99. Inthis way, the job ticket 61 reflects a hierarchical database structure. Thecontrol 

25 data 69 includes the specific instructions, parameters, and criteria for completing the task identified 

26 by the j ob ticket 6 1 . The control data 69 may also include specific data required to complete tasks 

27 defined in the j ob ticket 6 1 . The control data 69 may also be associated with each node in a node 

28 tree. 
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1 The security module 67 controls access to a specific job ticket. The security module 67 

2 may be implemented using standard encryption and access techniques, including public/private key 

3 infrastructures, for example. 

4 The client extension 64 may contain "custom" information, such as user age, credit card 



5 number and zip code. Information provided in the client extension 64 may be protected by use of 

6 a public key signature, or similar feature. Hence, all client extension information will automatically 

7 be included in aMessage Digest Protocol (MDP) and will affect the signature of the job ticket 61 . 

8 With the above-describe job ticket architecture, many Internet-related security issues are 

9 addressed, including IP spoofing, time controlled sessions, job ticket alterations, varying 
1 0 authorization levels, and client-dependent persistent data storing. 



1 1 The j ob ticket 6 1 shown in Figure 5 A may be used to refer to a specific content 5 1 in the 

12 j ob store 5 0 . Alternatively, multiple j ob tickets 6 1 may be used to refer a specific content 5 1 , or 

13 one job ticket 61 may be used to refer to multiple contents 51. Thus, for example, one job ticket 

14 61 may specify a repetitive printing task to be completed on similar documents, each of which has 

15 a different content 5 1 . 

1 6 Using the network 20 shown in Figure 3 , and the corresponding j ob ticket shown in Figure 

1 7 5 A, a client 3 1 may request and have completed many different electronic services. For example, 

1 8 the client 3 1 may use the network 20 as an e-mail application. 

1 9 Figure 5B shows the tasks section 68 in detail. The tasks section 68 may include one or 

20 more branch descriptors 66 that include information related to processing for that branch. A 

2 1 description segment 95 may define the tasks to be completed for each branch. Alternatively, the 

22 description segment 95 may provide a link, or handle, to a file that contains the branch description. 

23 The resources segment 96 lists input and output resources associated with the tasks defined for the 

24 branch. The lock/unlock flag segment 97 allows a flag to be set to lock and unlock a branch. A 

25 bid information segment 98 includes bid information gathered, for example, by the bidding service 

26 90. The bid information 98 may include detailed information such as the IP address of the 

27 processors authorized access to the branch, estimated performance information (e.g., estimated 
2 8 cost, delivery time), and other information. Alternatively, the bid information 98 may contain a link 

29 to another file containing the detailed bid information. The security segment 99 may indicate 

30 authorized security levels, and may be used as part of a public key/private key infrastructure. 
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1 Figure 5C illustrates an embodiment of the control data 69. The control data 69 includes 

2 a client address, which may be a machine address, such as an Internet protocol (IP) address. An 

3 expiration date/time segment may be used to terminate active status of the ticket 61. Once 

4 terminated, the ticket may be deleted from the job ticket service, and the corresponding content 

5 5 1 may be de-referenced. That is, the contents may no longer be referenced by a specific job 

6 ticket 61 . This feature may help eliminate stale data, and free up resources for other job requests 

7 32 (see Figure 7). Finally, the control data 69 may include specific performance requirements, such 

8 as cost an delivery, warranty, required materials, price reductions based on quantity, and other 

9 requirements, for example. 

I o The use of j ob tickets as XML obj ects allows clients to define databases, and to store data 

I I through thejobticketservice60andthejobstore 50. The databases may be used to hold contact 

12 lists, addresses, and other personal data. The databases may also be used to store any other 

13 generic data. The databases could then be used in conjunction with a variety of e-services 

1 4 provided by the processors 80 r For example, an e-mail processor 80 that provides e-mail services 

1 5 may be used in conj unction with a personal contact list to send e-mail messages, transfer electronic 

1 6 files, or to establish a chat room. The e-mail processor 80 may access the contact list at predefined 

1 7 intervals to send e-mail messages to a select group of e-mail addressees. Furthermore, because 

18 the service center 40 provides a single portal to processors 80 that are coupled to the 

1 9 communications network 3 5 , the client 3 1 need not have any knowledge of the database structure, 

20 or the processing requirements of the processors 80. 

21 In the specific application of the generic XML database to an e-mail service, the client 3 1 

22 may have established, as a generic database, a list of e-mail contacts. The contacts database may 

23 then be stored in the job store 50 as a content file 5 1 . A corresponding job ticket 61 may be 

24 stored at the j ob ticket service 6 1 . The j ob ticket 6 1 includes control data needed to send and 

25 receive e-mail through the service center 40. Furthermore, the job ticket 6 1 serves as apointer 

26 to data in the content file 51. In particular, thejob ticket 61 may store XML data that is related 

27 to other data stored in the content file 5 1 . 

28 Alternatively, the job ticket 61 may store the contacts data. This alternative takes 

29 advantage of the fact that the j ob ticket 6 1 includes a vocabulary that can be extended to include 
3 0 the contact data, and that the vocabulary can be further extended to include properties for each 
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1 contact in the contact data. For example, the j ob ticket 6 1 may specify that a contact is a business 

2 contact or apersonal contact. Other properties may also be included, such as whether the contacts 

3 in the contact database use mobile phones, land line phones, facsimile machines, and e-mail 

4 addresses. 

5 The use of the j ob ticket 6 1 also allows for parsing, searching and updating the contacts 

6 database. For example, the client 3 1 may desire to search the contacts database for phone 

7 numbers for all persons whose first name is Joe. This search functionality is included in the j ob 

8 ticket 6 1 , and allows the j ob ticket service 60 to provide the client with a list of phone numbers for 

9 all entries in the contacts database where the person' s first name is Joe. That is, the contacts 

1 0 database includes entries having the property of Joe, and the j ob ticket service is able to search the 

1 1 contacts database for this property, and to return a list of those entries to the client 3 1 . 

1 2 The properties function of the j ob ticket 6 1 also allows the j ob ticket service 60 to control 

1 3 specific tasks desired by the client 3 1 , or to indicate to the client that a desired task cannot be 

1 4 completed. Staying with the example of the contacts database, the client 3 1 may desire to send 

1 5 afacsimile transmission to all entries in the contact listthathave a specific zip code. The job ticket 

1 6 service 60 can search the contacts database by properties, looking for zip code. The j ob ticket 

1 7 service 60 can also search the contacts database to determine if any entry does not have a facsimile 

1 8 machine. For those entries that do not have a facsimile machine, the j ob ticket service 60 can 

1 9 originate a message to send back to the client 3 1 , informing the client 3 1 that the facsimile 

20 transmission was undeliverable. Usingthis functionality, theclient31 need not know anything about 

2 1 the intended recipients of the facsimile transmission. 

22 Returning to the example of an e-mail service, at the client 3 1 , an e-mail application may 

23 be launched in order to send an e-mail message, using the Internet, to one or more contacts in the 

24 contact database. However, the client 3 1 need not subscribe to any one Internet service provider. 

25 Instead, the service center 40 determines which processor 80 best suits the client' s needs for 

26 sending the e-mail message. That is, the service center 40 may select a e-mail service provider (a 

27 processor 80) to send the e-mail message to a chosen destination address. Furthermore, the 

2 8 service center 40 may determine, based on information maintained in the contact database (i.e., the 
29 content 5 1 in the job store 50), which delivery options are desired by a user at the destination 

3 0 address. For example, the destination address user may desire that all e-mail messages be sent to 
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1 an e-mail box, or that an alert be provided whenever an e-mail message is sent. These delivery 

2 features may be stored in the contact database in the job ticket 6 1 . Alternatively, the delivery 

3 features may be stored in a separate database (content file 5 1 ) in the j ob store 50, and the service 

4 center may retrieve information form this separate database when determining how to deliver the 

5 e-mail message. Specifically, the separate database may include a variety of users, along with the 

6 user' s Internet address. By comparing the Internet address provided with the out going e-mail to 

7 the Internet addresses in the separate database, the service center 40 can determine desired 

8 delivery options of the addressee. This process for determining delivery options is transparentto 

9 the client 3 1 that originated the e-mail message. All that the client 3 1 need know is the contact 

1 0 information (e.g., the Internet address or a contact name) . 

1 1 The client 3 1 may use the j ob ticket service 60 to specify a number of performance features 

1 2 related to the e-mail service. For example, the client 3 1 may want the service center 40 to attempt 

1 3 a specified number of delivery attempts, and if delivery does not occur, to send a return message 

14 to the client 3 1 indicating non-delivery of the e-mail message. 

1 5 In another application , the service center 40 may operate as a focal point for a client' s 

1 6 messaging systems. The service center may receive and store messages in the j ob store 50 , or 

17 within ajob ticket 61. Preferably, a separate content file 51 orjobticket61 is established for each 

1 8 client 3 1 having an account on the service center 40 so that all of the messages for a single client 

19 31 will be stored in the same directory. 

20 The network 20 shown in Figure 4 may include the necessary communications interfaces 

2 1 to support voice, e-mail, and facsimile transmissions. When a call arrives at the service center 40, 

22 a central processor (not shown in Figure 4) may read an incoming address signal from the 

23 originating user, and use the address to store the message in the appropriate job ticket 61 . 

24 In addition to handling incoming calls and storing the messages, the service center may 

25 coordinate a response from the client 3 1 . For example, the client may request a specific response 

26 (e.g., and out of office notice) to an e-mail message from a user. The responses may be stored as 

27 part of the client's content file 5 1 . The job ticket service 60 may access the content file 5 1 , and 

28 download an appropriate response message. Thejob ticket service 60 may then use aprocessor 

29 80 to deliver the response back to the originating user. 
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1 The job ticket service 60 may also include software to transform incoming messages (voice, 

2 facsimile) into XML files for storage in the content file 5 1 . 

3 The j ob ticket 6 1 or the content file 5 1 may contain the data indicating the preferences of 

4 the client 3 1 . Thus, for example, when a facsimile message in the TIFF/F format is retrieved by the 

5 service center 40, the job ticket service 60 may ascertain from the data in job ticket 61 the 

6 preferred option of displaying the facsimile message and would generate the appropriate HTML 

7 files. 

8 The service center 40 may be connected to a paging system processor 80. Upon the 



9 arrival of a new message, in addition to sending an e-mail message to the client' s mailbox, the 

1 0 service center 40 may also activate the paging system processor 8 0 so that a pager (not shown) 

1 1 would be activated. In this manner, the client 31 could receive almost instantaneous notification that 

12 a message has arrived. 

1 3 The service center 40 may use the data in the j ob ticket 6 1 to provide other information 

1 4 and alerts to the client. For example, the service center 40 may send a message to the client to 

1 5 indicate upcoming appointments, and special dates, such as birthdays. The client 3 1 may designate 

16 in the control data section of the j ob ticket 6 1 that birthday greeting be automatically sent to specific 

1 7 individuals whose information is stored in the j ob ticket 6 1 . 

1 8 The service center 40, when supporting client communications, may operate according an 

1 9 asynchronous manner. In an asynchronous mode of operation, information requested by the client 

20 31 may not be available and may have to be generated after the j ob request 32. The asynchronous 

2 1 mode of operation is preferred since fewer files are generated, thereby reducing the required 

22 amount of storage. Because the information requested by a client 31 may not be available, some 

23 anchors cannot specify the filename, such as "2.html," but will instead contain a command for the 

24 file. For instance, an anchor may be defined as<AHREF=/faxweb/clients/2496801/ 

25 viewpage.cgi?FAX.sub.--NUM=l&PAGE=l&VIEW.sub.--MODE=FULI>forcausingaCGI 

26 to run a viewpage program so that page 1 of facsimile message 1 will be displayed in a full size 



27 image. The CGI will generate the requested information when the information has not been 

28 generated, otherwise the CGI will retrieve the information and relay the information for transmission 

29 to the client 31. 

30 The service center 40 can reliably receive voice, facsimile, and data messages for aplurality 
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1 of clients 3 1 and can receive more than one message for a client 3 1 at a single time. The messages 

2 are stored by the service center 40 and can be retrieved at the client' s convenience at any time by 

3 connecting to the service center 40. 

4 This use of the service center 40 provides a great number of benefits. The client 3 1 would 



5 not need a facsimile machine, voice mail system, or a machine dedicated for receiving data 

6 messages. The client 3 1 also need not worry about losing part of the message or violating the 

7 confidential nature of the messages. The client 3 1 , of course, can still have a facsimile machine and 

8 dedicated computer for data messages. The service center 40, however, will permit the client 3 1 

9 to use the telephone company ' s call forwarding feature so that messages may be transferred to the 
1 0 service center 40 at the client' s convenience, such as when the client 3 1 is away from the office. 



1 1 Furthermore, the client 3 1 may be provided with a greater or fewer number of options in 

1 2 displaying or retrieving messages. The options may permit the client 3 1 to review or retrieve the 

1 3 messages in other formats. The options may also permit a client 3 1 to j oin two or messages into 

14 a single message, to delete portions of a message, or to otherwise alter the contents of the 

15 messages. 

1 6 The service center 40 may restrict a client 3 1 to only certain types of messages. For 



1 7 example, a client 3 1 may want the service center 40 to store only facsimile messages in order to 

18 reduce costs of using the service center 40. In such a situation, the service center 40 would 

1 9 perform an additional step of checking that the type of message received for a client 3 1 is a type 

20 of message that the service center 40 is authorized to receive on the client' s behalf. When the 

2 1 message is an unauthorized type of message, the service center 40 may ignore the message entirely 

22 or the service center 40 may inform the client 3 1 that a user attempted to send a message to the 

23 service center 40. 

24 The service center 40 has been described as converting the messages into XML and 

25 transmitting the XML files to the client 3 1 . The XML format, however, is only one format for 

26 exchanging information on the Internet and is actually only one type of a Standard Generalized 

27 Mark-Up Language. The service center 40 is therefore not limited to the XML format but may be 

28 practiced with any type of mixed media page layout language that can be used to exchange 

29 information on the Internet. 

3 0 According to an embodiment, the service center 40 may be used as a file repository serving 
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1 as an archive for a particular client 3 1 or group of clients 3 1 . As described above, the service 

2 center 40 may maintain a list of all messages for a particular client 3 1 , which is displayed to the 

3 client 3 1 when the client 3 1 accesses a mailbox. The service center 40 may store all messages, 

4 whether they are voice, facsimile, or data, for a client 3 1 in the database indefinitely. The service 

5 center 40 may therefore be relied upon by a client 3 1 to establish the authenticity of a message and 

6 the existence or absence of a particular message. Through the service center 40, a client 3 1 can 

7 therefore maintain an accurate record of all received email messages, facsimile messages, and data 

8 transfers. 

9 In addition to serving as a file depository, the service center 40 may also function as a 

1 0 document management tool. When the service center 40 receives a message, the service center 

11 40 updates a database (content file 51) with information on the message. This information includes 

1 2 the type of message, whether it is a facsimile message, voice message, or data message, the time 

1 3 and date at which the message was received, the size of the file, such as in bytes, the telephone 

1 4 number of the caller leaving the message, as well as other information, such as the number of pages 

15 of a facsimile message. Because the address (e.g., atelephone number or e-mail address) called 

16 is unique for each client 3 1 , the information also includes the intended recipient of the message. 

1 7 As noted above, the job ticket 6 1 , in conjunction with other components of the service 

1 8 center 40, may also be used to create a persistent, generic obj ect-based data structure, such as an 

1 9 XML database. An example of the use of a j ob ticket 6 1 for this purpose is illustrated in Figure 

20 5D. Thejob ticket 61 includes a contacts list 84, which may be in the form ofan XML database, 

21 or some other generic database. The contacts list 84 may include a structure with entries for 

22 business 85 and personal 86 use. The business 85 and personal 86 contacts structures may include 

23 entries of individuals 87, as shown. Each of the entries 87 may include specific properties, as 

24 defined above. In addition, or alternatively, each of the entries 87 may include links to other 

25 databases that provide additional information and properties about the individual. 

26 While the use of the j ob ticket 6 1 as a XML database has generally been described with 

27 reference to an e-mail and messaging service, the j ob ticket 6 1 is not so limited. Any data that is 

28 capable ofbeing stored in a database may be accesses and controlled using thejob ticket 61. 

29 The features described above, and shown in Figures 5 A-5D may be replicated in another 

30 embodiment of a job ticket 61 in which all datarelatedto a specific node orbranchis located with 
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1 that node or branch. Using the example node-tree 1 0 shown in Figure 2, each node (branch) may 

2 include detailed information, and features such as resources, authorized processors 80 i3 

3 lock/unlocked flag, bid information, branch description, and other information. 

4 Figure 6 is a diagram of functions of the job ticket service 60. The primary functions of the 

5 job ticket service 60 are to store 73 the job tickets 6 1 , and to provide access 75 to the job tickets 

6 6 1 , to users such as the client 3 1 and to the processors 80,. To accomplish these storage and 

7 access functions, the j ob ticket service 60 may create a j ob ticket reference 72 and a j ob resource 

8 reference 74. The job ticket service 60 also controls job content access 76, updates 77 the job 

9 tickets 61, as processes are completed and reported by the processors 80„ completes the job 

10 tickets 61, and reports 78 when all processes are completed for a specific job ticket 61, and 

1 1 provides an approval process 79 to allow a client 3 1 to approve completion of the tasks designated 

12 in the job ticket 61. 

1 3 The job ticket reference 72 includes a specific reference to a corresponding job ticket 6 1 ,. 

14 The job ticket reference 72 may be used by the job ticket service 60 to allow one or processors 

1 5 80, and clients 3 lj to access the job ticket 61 . That is, instead of passing the job ticket 61 to a 

16 processor 80, the job ticket service 60 passes the job ticket reference 72. With the job ticket 

1 7 reference 72, the processor 80 may access all or a part of a job ticket 6 1 so that the processor 80 

1 8 may complete one or more processes. Unlike conventional job ticket services, the job ticket 

1 9 service 60 retains the j ob ticket in storage 73 , and only permits users (clients 3 1 and processors 

20 80) to access the job ticket 61 . This feature allows multiple processors 80 to simultaneously 

21 complete processes for the specific job request 32 related to the job ticket 61. 



22 The j ob ticket service 60 may also create a resources reference 74, and may provide the 

23 resources reference 74 to the processors 80 and the clients 3 1 in a manner similar to that of the j ob 

24 ticket reference 72. As noted above with the description accompanying Figure 2, the resources 

25 may include physical devices and materials, and may include digital files. Use of the resources 

26 reference 74 may simplify data included in the job ticket 61. 

27 Alternatively, information contained in the resources reference 74 may be included in the 

28 j ob ticket 6 1 , or may be included in other files accessed by the clients 3 1 , and the processors 80,. 

29 Figure 7 is a diagram showing operation of selected functions of the j ob ticket service 60. 

30 As shown in Figure 7, the job ticket service 60 includes a job ticket 61 u which may be a 

HP:10005661-1 24 



1 programming obj ect such as that represented in Figure 2, and described above . The j ob ticket 6 1 1 

2 is shown supplied to the job ticket service 60 bythe client 31 x . TheclientSl! maybe a networked 

3 computer or similar device that is capable of transmitting the digital information representing the j ob 

4 ticket 61 j to the job ticket service 60. To ensure the job ticket 61 , arrives atthe job ticket service 

5 60, thejob ticket 61 j may contain areference to thejob ticket service 60, such as the service ID 

6 65 illustrated in Figure 5 A. The service ID 65 may include a network address of the job ticket 

7 service 60. For example, the service ID 65 may include auniversal resource locator (URL) if the 

8 job ticket service 60 is an Internet web site. 

9 Also shown in Figure 7 are client 3 1 2 and processors &Q X - 80 N . The processors 80! - 80 N 

1 0 may include networked resources such as networked printers, electronic-commerce entities, such 

11 as Internet web sites, and "brick and mortar" entities, such local print shops that are coupled to the 

12 job ticket service 60 using the service bus 41 . 

13 The client 31 generates ajob request 32 (content 51 andjob ticket data). Usingthefront 

1 4 end service 3 0 (not shown in Figure 7) and the service bus 4 1 , the client 3 1 1 sends thejob ticket 

1 5 data to thejob ticket service 60 and the content 5 1 (not shown in Figure 7) to thejob store 50. 

1 6 The j ob ticket service 60 may pass the j ob ticket data to the work flow controller 70, which will 

17 create ajob ticket 61. The content 5 1 1 and thejob ticket 61 x are related by thejob ID 63 . The 

18 job ID 63 also includes an identification of the job store 50, and a location within thejob store 50 

1 9 in which the content 5 1 1 is stored. In an alternate embodiment, the content 5 1 r may be stored at 

20 the client 3 1 1 , and may then be accessed by other users through the service bus 4 1 and the front 

21 end service 30. 

22 The j ob ticket 6 1 1 specifies processes that must be completed to finish the j ob request 3 2 . 

23 As noted above, Figure 2 illustrates processes required to print a brochure, including the inside 

24 pages and the cover. More that one processor 80 : may be required to complete such a job 

25 request, or to complete the j ob request in the most cost-efficient and/ or timely manner. The work 

26 flow controller 70 (not shown in Figure 7) can determine which of the processors 80 r 80 N should 

27 complete a specific process, and, if necessary, the order in which such processes should be 

28 completed. The work flow controller 70 may poll the various processors 80j to determine which 

29 may be used to complete thejob request. The work flow controller 70 may then notify selected 

30 processors 80, that a job request has been registered with the job ticket service 60. 
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1 For each j ob ticket 6 1 , received, the j ob ticket service 60 creates a reference to the 

2 jobticket61,. Theprocessor80imayrequestaccesstothejobticket61 inorderto complete one 

3 or more processes. In response, the j ob ticket service 60 provides the processor 80! with the job 

4 ticket reference 72 j. The job ticket reference 72 1 is then used as an index to the job ticket 61 lf 

5 The j ob ticket reference 72 x may also be provided to other processors, such as the processor 80 2 , 

6 and to other clients, such as the client 3 1 2 . The processor 80 2 and the client 3 1 2 may then access 

7 the job ticket 6^ at the same time as the processor 80 x accesses the job ticket 61 x . This 

8 simultaneous access allows different processes to be completed in parallel. In the example 

9 illustrated in Figure 2, the processor 80 x may complete some or all the processes for the inside 

10 pages, and the processor 80 2 may complete the processes for the cover. 

1 1 Figure 8 is a block diagram illustrating an example application of the control features of the 

12 job ticket service 60. Thejob ticket 61 1 isreferenced to the job content 51j by the job ticket ID 

13 63 , and information related to the job ticket 6 1 x and the job content 5 1 x is passed over the service 

14 bus 4 1 . The processors 80 t can access the j ob content 5 1 x and the j ob ticket 6 1 x using the service 

15 bus 41 . In the illustrated example, thejob ticket 61 , refers to ajob request 32 to print abrochure 

1 6 using the processes outlined in Figure 2. The processor 80! is designated by the work flow 

1 7 processor 70 to produce the inside pages of the brochure and the processor 80 2 is designated to 

18 produce the brochure cover. The processor 80i passes ajob ticket access request to thejob 

1 9 ticket service 60 . The access request may include security information that allows the processor 

20 80! to access the j ob ticket 6 1 1 and the corresponding content 5 1 x or j ob. In response, the j ob 

21 ticket service 60 provides ajob ticket reference 62! that is used by the processor 80j to access 

22 thejob ticket 61^ The processor 80! may use information in thejob ticket 61! to access the 

23 content 5 1 x stored in the job store 50. Since the processor 80j will produce only the inside pages, 

24 the processor 80j will not need access to all the information contained in the job ticket 61 x . 

25 Furthermore, because thejob ticket 6 1 1 remains in the job ticket service 60, other entities, such 

26 as the processor 80 2 , may continue to access the job ticket. 

27 As the processor 80i completes various processes, the processor 80 x may update the 

28 content 5 1 1 and the j ob ticket 6 1 1 . Thus, the j ob ticket 6 1 x may reflect the latest status of the job 

29 request 32. The status reports may indicate when a node in the node tree 1 0 is completed, when 

30 an interim deadline is completed, when another processor may be used to complete a process, and 
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1 when all processing is complete. The status report may be included in a digital file that is used by 

2 the work flow controller 70, for example. The status report may also be included in a human- 

3 readable format, such as a pop-up window on a computer display screen. The processor 80 x may 

4 receive the job ticket reference 72 ls and may complete all scheduled processes, returning the job 

5 ticket reference 72 1 to the job ticket service 60. The processor 80! may also send a copy of the 

6 job ticket reference 72! to the processor 80 2 , so that the processor 80 2 may access the job ticket 

7 6 1 j , and the content 5 1 1 and produce the brochure cover. 

8 Figure 9 is a flowchart illustrating an operation 1 00 of the j ob ticket service 60. The 

9 operation 1 00 is based on completing the inside pages nodes shown in Figure 2. The operation 

10 100 may be at least partly under the control of the work flow controller 70, or some equivalent 

1 1 device. The operation 1 00 assumes that a job request 32 (job ticket data and content) have been 

1 2 passed to the service center 40, and that a j ob ticket service 60 has been created. The operation 

13 100 begins at start block 101. In review and assign processors block 105, the work flow 

1 4 controller 70 determines which processors 80j are able and available to complete the job. The 

1 5 work flow controller 70, or the optional bidding service 90 may use polling or bidding features to 

16 make the determination. If more than one processor 80j is available, and can satisfy the 

1 7 requirements of the j ob ticket 6 1 , the work flow controller 70 may assign one specific processor 

18 80tothejob. Alternatively, the work flow controller 70 may provide a list of processors 80 t to 

1 9 the client 3 1 , and allow the client 3 1 to select one or more processors 80,. 

20 In request job ticket block 1 1 0, a processor 80, having been authorized access to a job 

21 ticket 61, sends an access request to the job ticket service 60 using the servicebus41. Inblock 

22 115, the job ticket service verifies that the processor 80 may access the j ob ticket 6 1 . Access may 

23 be controlled by a password, an identification, and apublic key/private key security system, for 

24 example. In block 1 1 5, if the processor 80 is denied access, an error signal may be sent to the 

25 processor and/or the client 3 1 , block 120. 

26 Inblock 1 1 5, if access is authorized, the job ticket service 60 provides the processor 80 

27 withacopy ofthejobticketreference72correspondingtothejobticket61, block 125. Thejob 

28 ticket reference 72 allows the processor 80 to access thejob ticket at any time. By accessing the 

29 job ticket 6 1 at any time, the processor 80 is able to view an updated version of the j ob ticket 6 1 

30 as changes are made to the job ticket 61 by other entities, including other processors 80. 
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1 In block 1 30, the job store 50 provides access to the job content 5 1 that is referenced by 

2 thejob ticket 61. Only that part of the content 5 1 that may be needed by the processor 80 may 

3 be supplied by thejob store 50. For example, if the processor 80 is only to generate the inside 

4 pages of the brochure, the j ob store 50 may not provide access to the content required to produce 

5 the brochure cover. After receiving the j ob ticket reference 72 and the content 5 1 , the processor 

6 80 may perform one or more tasks using input resources to produce an interim or final output 

7 resource. With completion of each node in the node tree 1 0, the processor 80 may provide an 

8 input to thejob ticket service 60 to allow modification of thejob ticket 61, block 135. If the 

9 processor 80 completes all required processes, the processor 80 may provide a final status report 
10 to the job ticket service 60, block 140, alongwithanyfmalmodificationstothejobticket61. 



1 1 Inblock 145, thejob ticket service 60 and the work flow controller 70 determine if any 

1 2 additional tasking may be required. If additional tasks are required, the work flow controller 70 

1 3 will ensure the appropriate processors 80 are assigned, and the operation returns to block 1 1 0. 

14 If no additional processes are required, the operation moves to block 1 50 and ends. 

15 Figure 10 is a flowchart illustrating the routine 105 for developing a work flow and assigning 



1 6 processors to the work flow. The process starts in block 200. In block 205, the service center 

17 40 receives a job request 32. The job request 32 may specify performance requirements, 

1 8 resources, and other parameters, and may include content 5 1 , or a link to the content 5 1 . In block 

19 2 1 0, the work flow controller 70 defines a work flow to accomplish the tasks specified in the j ob 

20 request 32. The work flow may be represented by a node tree, such as the node tree 1 0 shown 

21 in Figure 2. 



22 Inblock 230, the work flow controller 70 generates a job ticket 61 using the information 

23 provided by the j ob request 3 2, the work flow generated in block 210, and an appropriate j ob 

24 ticket template. Thejob ticket 61 is then stored in the job ticket service 60. Any content 5 1 may 

25 be stored in the job store 50. 

2 6 The work flow controller 70 or the j ob ticket service 60 may create a j ob ticket notice, or 

27 other object, and may post the notice, block 250, at the service center 40 so that outside entities 

2 8 (e.g., the processors 80) may acquire sufficient information to bid on completion of the job ticket 

29 61, or abranch 66 of the job ticket 61. In an alternative embodiment, thejob ticket 61 maybe 

30 posted at the service center 40. If the job ticket 61 is posted, the job ticket 61 may include 
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1 mechanism to limit access to the j ob ticket or to limit access to certain portions of the j ob ticket 6 1 . 

2 For example, the client extension 64 may not be accessible to the processors 80. 

3 In block 270, the service center 40 receives bids from specific processors 80 and in block 

4 290, the service center 40 evaluates the bids. In block 295, the service center 40 determines if the 

5 client 3 1 submitting the job request 32 intends to select the winning bid(s), or if the service center 

6 40 makes the selection. If the client is to make the selections, in block 3 00, the service center 40 

7 provides the bid information to the client 3 1 . Then, in block 305, the service center 40 receives 

8 the selections from the client 3 1 . If the service center 40 is to make the selections, in block 310, 

9 the service center 40 selects the winning bid(s). In block 3 1 5, the service center notifies the 

1 0 winning processors. The service center may also store the bid information with the corresponding 

11 job ticket 6 1 . In block 320, the routine 1 05 ends. 

1 2 Figure 1 1 is a flowchart illustrating the sub-routine 2 1 0 for defining a work flow. The sub- 

1 3 routine 2 1 0 starts in block 3 50. In block 3 55 , the work flow controller 70 determines if the work 

1 4 flow will contain multiple branches. If the work flow will contain multiple branches, the work flow 

15 controller 70 defines the branches, block 3 60. In block 365, the work flow controller 70 selects 

16 a branch for which resources and processes are to be defined. In block 370, the work flow 

17 controller 70 defines input resources for a first process, or node. In block 375, the work flow 

1 8 controller 70 defines the tasks to be completed for the first process . In block 3 80, the work flow 

1 9 controller 70 determines the output resources of the first process. In block 385, the work flow 

20 controller 70 determines if another process is required for the work flow or branch. In no 

2 1 additional processes are required, the work flow controller 70 determines if another branch is to 

22 be defined, block 3 90 . If another branch is to be defined, the work flow controller 70 selects 

23 another branch, block 365, and the sub-routine 210 continues. If another branch is not to be 

24 defined, the sub-routine 2 1 0 ends, block 395. The results of the work flow definition may be 

25 incorporated into the job ticket 6 1 (see Figure 1 0, block 230). 

26 Figure 12 is a flow chart illustrating the sub-routine 250 of posting ajob ticket notice or job 

27 ticket. The sub-routine 250 starts in block 400. In block 405, the work flow controller 70 

28 determinesiftheworkflowassociatedwiththejobticket61 includes multiple branches. Ifthe 

29 work flow does not include multiple branches, the work flow controller posts the j ob ticket notice 
3 0 listing the single branch, block 410. Ifthe work flow includes multiple branches, the work flow 
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1 controller 70poststhejobticketnotice withmultiple branches, block 420. The sub-routine 250 

2 then ends. 

3 Figure 1 3 is a flow chart illustrating the sub-routine 290 for evaluating bids. The sub- 

4 routine starts in block 440. Inblock445,thebiddingservice90selectsafirstbidforanalysis. In 

5 block 450, the bidding service 90 determines if the client 3 1 has supplied any evaluation criteria or 

6 requirements. If the client has not supplied evaluation requirements, the bidding service 90 

7 compares the selected bid to a set of standard, minimum performance requirements, which may be 

8 industry-standard requirements, block 45 5 . In block 460, the bidding service 90 determines if the 

9 bid meets the minimum performance requirements. If the bid does not meet the minimum 

1 0 performance requirements, the bid is rejected, block 475. If the bid is rejected, the bidding service 

1 1 90 determines if additional bids were submitted, block 495 . If additional bids were submitted, the 

12 bidding processor 90 returns to block 445 and selects the next bid for evaluation. 

1 3 If in block 450, the client 3 1 has supplied performance requirements, the bidding service 

14 90 compares the selected bid to the client-supplied performance requirements, block 465. In 

1 5 block 470, the bidding service 90 determines if the selected bid meets the minimum criteria of the 

1 6 client-supplied performance requirements. If the minimum criteria are not met, the bidding service 

17 90 rejects the bid, block 475. 

18 In blocks 470 and 460, if the minimum criteria are met, the bidding service 90 determines 

1 9 if the client 3 1 has supplied an evaluation algorithm. If the client 3 1 has not supplied an evaluation 

20 algorithm, the bidding service applies a standard evaluation algorithm, which may be an industry- 

2 1 standard algorithm, block 485. If the client has supplied an evaluation algorithm, the bidding service 

22 90 applies the client-supplied evaluation algorithm, block 490. The bidding service 90 may then 

23 store the results of the algorithm pending evaluation of all bids. 

24 In block 495, the bidding service 90 determines if any bids remain to be evaluated. If 

25 additional bids remain, the sub-routine 290 returns to block 445, and the bidding service selects 

26 the next bid for evaluation. In block 495, if no additional bids remain for evaluation, the bidding 

27 service 90 ranks the bids, block 500. The sub-routine 290 then ends, block 505. 

28 Figure 14 is a flowchart illustrating the routine 130 forproviding accessto ajobticket61 . 

29 Theroutine 130beginsinblock510. Inblock515,thejobticketservice60receivesajobticket 

30 reference 72 from a processor 80, and retrieves the corresponding job ticket 61, block 520. 
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1 In block 525, the j ob ticket service 60 compares the processor identification to processors 

2 listed in the job ticket 61 orbranches66ofthejobticket61. Thejob ticket service 60 determines 

3 if the selected branches 66 axe locked, block 53 0. If the selected branches 66 are not locked, the 

4 job ticket service 60 copies the selected branches 66 to the processor 80, block 535. In block 

5 5 50, the j ob ticket service 60 then determines if the selected branches 66 require locking. If the 

6 selected branches do not require locking, the routine 130 ends, block 560. Ifthe selected branches 

7 66 require locking, thejob ticket service 60 locks the selected branches 66, block 555. The 

8 routine 130 then ends, block 560. 

9 In block 530, ifthe selected branches 66 are locked, thejob ticket service 60 determines 

1 0 ifthe processor 80 intends to modify information in the selected branches 66, block 540. Ifthe 

1 1 processor 80 will not modify the selected branches 66, the j ob ticket service 60 may provide an 

1 2 error message, block 545. Ifthe selected branches 66 will be modified, thejob ticket service 60 

13 may unlock the selected branches 66, block 547. 

1 4 Figure 1 5 is a flow diagram of a method for allowing access to a j ob ticket 6 1 . The method 

1 5 may execute as part of the routine 1 1 5 shown in Figure 9. The method starts with block 600. In 

1 6 block 605 , the authentication server 94 receives authentication information from a processor 80 

1 7 and retrieves a j ob ticket 6 1 corresponding to a job ticket reference 72 possessed by the processor 

1 8 80. At this stage of the process, thejob ticket 6 1 (excluding the public key signature field 67) 

1 9 contains two information fields, the framework 62 and the client extension 64. The framework 62 

20 contains information such as the service ID, client IP address, expiration date and time, and 

2 1 processor authorization, as previously described. The client extension 64 contains information such 

22 as credit card number and zip code, also previously described. The information in the j ob ticket 

23 61 (excluding the public key signature field 67) is then, for example, optionally hashed using, for 

24 example, MD5 protocol, and encrypted with a public key encryption system, block 610, generating 

25 a hash number, block 615. Other hashing or encryption techniques may also be used. The hash 

2 6 number is representative of the specific information contained in the j ob ticket 6 1 . The hash number 

27 generated in block 61 5 is then encrypted using a standard public key encryption system, block 620. 

28 Encrypting the hashnumber with aprivate key prevents any user without knowledge of the public 

29 key from modifyingthe job information. Inblock 625, thejob ticket 61 and the encrypted hash 

3 0 number are concatenated to generate the completed j ob ticket 6 1 . Hence, the completed j ob ticket 
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1 61 information fields: 1) the framework 62, 2) the client extension 64, and 3) the public key 

2 signature (encrypted hash number) 67. The method then ends, block 630. 

3 Figure 16 illustrates a process 700 for using the service center 40 for document 

4 management purposes, with reference to Figure 4. The process starts in block 705 . A client 3 1 

5 sends a search request to the service center 40 for a particular document or set of documents, 

6 block710. Theclient31 mayissuetMsrequestwiththejobrequest32byclickingonalink,such 

7 as a link to "Search Documents," which may be presented to the client 3 1 by the service center 40 

8 after the client 3 1 has been granted accesses to the client' s mailbox. The service center 40 may 

9 present the client 3 1 with the option to search the document archives at other times, such as when 

1 0 the client 3 1 first attempts to access the mailbox, or when the URL received by the service center 

11 40 points toward the document archives. 

12 In response to this request, the service center 40 sends the client 31a search query form 

13 at block 7 1 5 to allow the client 3 1 to define a desired search. The search query form may include 

1 4 an entry for each of the data fields in the content file 5 1 . For example, the client 3 1 may input one 

1 5 or more names for a recipient and have the service center 40 search for all messages or files 

16 directedtojustthoserecipients. The client 31 may also indicate the type of document, such as 

1 7 whether it is afacsimile, voice message or data file. The search query form also has entries for the 

1 8 date or time, which preferably accept ranges of times and dates, and an entry for the telephone 

1 9 number of the caller to the service center 40 . The search query form may also include an entry for 

20 the size of the file or for the number of pages, which is relevant if the message is a facsimile 

2 1 message. The search query form may also include an entry for the document number, which may 

22 accept a range of document numbers, and also an entry for another field. 

23 At block 720, the client 3 1 enters the search parameters in the search query form and 

24 returns the information to the service center 40. The client 3 1 may define the search about any one 

25 data field or may define the search about a combination of two or more data fields . For example 

26 the client 3 1 may define a search by designating the document type as a facsimile and the calling 

27 number as (XXX) 249-680 1 . Once the client 3 1 has finished defining the search, the client 3 1 then 

28 selects the "SEARCH" link shown at the bottom of the screen whereby the client would send the 

29 completed search query form to the service center 40. 

30 At block 725, the service center receives the completed search query form and, through 
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1 a CGI, invokes one or more of the application programs 3 1 for performing the desired search for 

2 any files or messages falling within the parameters of the search. The results of the search are 

3 passed from the service center 40 through the CGI, at block 73 0, and returned to the client 3 1 . 

4 The service center 40 may return the search results in the form of a listing of all files or messages 

5 contained within the search parameters. 

6 At block 73 5, the client 3 1 selects the desired file or message from the listing of messages 

7 and files. For example, by clicking on the first listed document, the client 3 1 sends a request to the 

8 service center 40 for a viewing of that document and, in response, the service center 40 provides 

9 a viewing of the document according to the defined preferences of the client 3 1 . The client 3 1 may 

1 0 receive a reduced size image of the first page, a full size image of the first page, reduced size images 

1 1 of all pages, or full size images of all pages of the facsimile message. 

12 At block 735, the client 3 1 may also have the service center 40 save the search results. 

1 3 For example, the client 3 1 may input the name of JOE' s FACSIMILES as the name for the search. 

1 4 By clicking on a "SAVE SEARCH AS" link, the name of the search is provided from the client 3 1 

15 to the service center 40. At the service center 40, the CGI invokes an application program 31 to 

16 store the results of the search in the content file 5 1 under the designated name. The invoked 

1 7 application program preferably does not store the contents of all messages but rather stores a listing 

18 of the search results in the content file 5 1 . 

19 In the illustrated embodiments, the service center 40, and its sub-components, including the 

20 work flow controller 70 and the j ob ticket service 60, for example, may be implemented as a single, 

2 1 special purpose integrated circuit (e.g., an ASIC) having amain or central processor section for 

22 overall, system-level control, and separate circuits dedicated to performing various different 

23 computations, functions and other processes under control of the central processor section. Those 

24 skilled in the art will appreciate that the service center 40 may also be implemented using a plurality 

25 of separate, dedicated or programmable integrated or other electrical circuits or devices (e.g. , 

26 hardwired electronic or logic circuits such as discrete element circuits, or programmable logic 

27 devices such as PLDs, PL As, or PALs) . The service center 40 may also be implemented using 

28 a suitably programmed general purpose computer, e.g., a microprocessor, microcontroller or other 

29 processor device (CPU or MPU), either alone or in conjunction with one or more peripheral (e.g. , 

30 integrated circuit) data and signal processing devices. In general, any device or assembly of 
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1 devices on which a finite state machine capable of implementing the flowcharts shown in Figures 

2 9-16 can be used as the service center 40, or its sub-components. 

3 The terms and descriptions used herein are set forth by way of illustration only and are not 

4 meant as limitations. Those skilled in the art will recognize that many variations are possible within 

5 the spirit and scope of the invention as defined in the following claims, and their equivalents, in 

6 which all terms are to be understood in their broadest possible sense unless otherwise indicated. 
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